fix: SwiftBuddy app version permanently stuck at 1.0 (build 1) - #162
Merged
Conversation
generate_xcodeproj.py regenerates project.pbxproj fresh on every build (it's gitignored, not a checked-in file), and MARKETING_VERSION/ CURRENT_PROJECT_VERSION were hardcoded literals in its template. Neither release.yml (which releases roughly daily, tagged bNNN by commit count) nor build-dmg.yml ever touched them, so every DMG and app bundle ever built — regardless of commit or release tag — reported itself as "SwiftBuddy 1.0" build "1". scripts/build_dmg.sh already reads the real CFBundleShortVersionString out of the built app for the DMG filename, so this was silently naming every DMG SwiftBuddy-macOS-v1.0.dmg too. Makes both values overridable via env var (SWIFTBUDDY_MARKETING_VERSION, SWIFTBUDDY_BUILD_NUMBER), defaulting to the previous hardcoded values when unset so local/manual `python3 generate_xcodeproj.py` runs are unaffected. release.yml and build-dmg.yml now set: - build number = `git rev-list --count HEAD`, the same counter release.yml already uses for its bNNN release tags, so the app's build number and its release tag always agree. - marketing version = build date (YYYY.MM.DD) — always distinct per day, no manual "when do we bump this" decision needed for a pipeline that releases on close to a daily cadence. build-dmg.yml's checkout also gained fetch-depth: 0 — needed for `git rev-list --count HEAD` to see full history (it was a shallow clone; release.yml already had this for the same reason). Verified locally: `python3 generate_xcodeproj.py` with no env vars set reproduces the exact previous hardcoded output (1.0/1); with SWIFTBUDDY_MARKETING_VERSION/SWIFTBUDDY_BUILD_NUMBER set, both interpolate correctly into the generated project.pbxproj.
… actual file
Now that the DMG is versioned (SwiftBuddy-macOS-v<date>.dmg, from the
previous commit), the release notes' 'Download the attached
SwiftBuddy-macOS.dmg below!' line is wrong on every release — the
attached file's actual name now changes daily. The upload step itself
uses a glob (output/*.dmg) so the upload was never broken, only the
prose pointing at a specific filename. Matches the wording the Quick
Start section two lines down already uses ('Download the attached DMG
and open it') rather than trying to thread the shell-local
SWIFTBUDDY_MARKETING_VERSION value into a step that has no access to
it.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
The app's displayed version never changed across any release, ever. Root cause:
SwiftBuddy/generate_xcodeproj.pyregeneratesproject.pbxprojfresh on every build (it's gitignored, not a checked-in file), andMARKETING_VERSION/CURRENT_PROJECT_VERSIONwere hardcoded literals baked into its template. Neitherrelease.yml(which releases roughly daily, taggedbNNNby commit count) norbuild-dmg.ymlever touched them, so every DMG and app bundle ever built — regardless of which commit or release tag it came from — reported itself as "SwiftBuddy 1.0" build "1".scripts/build_dmg.shalready readsCFBundleShortVersionStringfrom the built app for the DMG filename, so this silently named every DMGSwiftBuddy-macOS-v1.0.dmgtoo.Fix
generate_xcodeproj.pynow reads both values from env vars (SWIFTBUDDY_MARKETING_VERSION,SWIFTBUDDY_BUILD_NUMBER), defaulting to the previous hardcoded values when unset — local/manualpython3 generate_xcodeproj.pyruns are unaffected.release.ymlandbuild-dmg.ymlnow set:git rev-list --count HEAD, the same counterrelease.ymlalready uses for itsbNNNrelease tags, so the app's build number and its release tag always agree.YYYY.MM.DD) — always distinct per day, no manual "when do we bump this" decision needed for a pipeline that releases close to daily.build-dmg.yml's checkout gainedfetch-depth: 0— it was a shallow clone, sogit rev-list --count HEADthere would've returned ~1 regardless of actual history (release.ymlalready had this for the same reason).Verification
Ran
python3 generate_xcodeproj.pylocally:MARKETING_VERSION = 1.0,CURRENT_PROJECT_VERSION = 1) — confirms no behavior change for local/manual runs.SWIFTBUDDY_MARKETING_VERSION=2026.08.27 SWIFTBUDDY_BUILD_NUMBER=703: both values interpolate correctly into the generatedproject.pbxproj.Both workflow YAML files validated with
yaml.safe_load.Test plan
generate_xcodeproj.pywith and without env vars.